The present invention relates to data processing, and more specifically, to cryptography methods and structures.
Vendors of security software have proprietary key management data structures and control mechanisms to aid in the implementation of customer key management policies. These data structures are called key tokens or key blocks. Recently, as the need for increased security has grown, different entities have begun to use varied key management data structures from different vendors. This has led to a need for an interface between such varied key management data structure systems of the different vendors.
A technical report (TR) was thus developed through the American National Standards Institute (ANSI) X9 working group to create a format for key exchange between interested parties. This format is referred to as TR-31 and specifies that the layout of a standardized key block includes several data fields for key type, algorithm and control, as well as wrapping mechanisms that use another key to wrap the key as an opaque data block placed in a payload after the key block. The wrapping mechanism specifies a method of cryptographically binding key control information into the key block as part of the wrapping mechanism. In particular, a TR-31 key block defines attribute fields for key usage, key management and wrapping information along with several other fields for other purposes. A TR-31 key block does not, however, specify methods for mapping proprietary key data structures to the TR-31 key block.
For example, a given cryptographically enabled computing system may include a hardware security module (HSM) that implements a Common Cryptographic Architecture (CCA), which specifies a byte array of key control information (i.e., a Control Vector (CV)), which is cryptographically bound in a key token to a cryptographic key. In this case, the CV controls the key control information inside the HSM secure boundary and concerns key usage and key management, with data representing a key type, a key sub-type, key management policies and key usage policies. The key type is the broad capability the key may be used for, such as enciphering and/or deciphering data, wrapping or unwrapping keys, computing or verifying message authentication codes, use in various financial operations, such as encrypting or decrypting PIN information, and generating or verifying PIN information. The key sub-type is a restriction on key capability within actions supported by the key type, such as limiting the key to only be used for enciphering data or deciphering data, but not for both. Key management policies controls how the key may be distributed (or not distributed), such as whether the key is exportable to another system (at all) and, if so, whether it is exportable while being wrapped in a TR-31 key block. The key usage policies controls how the key may be used beyond those limits imposed by type and sub-type, such as limits on types of data that can be processed (for keys that will be encipher/decipher keys) or types of keys that may be wrapped with the key (for keys that will be used for wrapping/unwrapping other keys). As mentioned above, methods for translating such CCA CV data into a representation appropriate for the TR-31 key block have not been specified.